Increasing advances in computer technology (e.g., microprocessor speed, memory capacity, data transfer bandwidth, software functionality, and the like) have generally contributed to enhanced computer application in various industries. Ever more powerful server systems, which are often configured as an array of servers, are commonly provided to service requests originating from external sources such as the World Wide Web, for example.
As the amount of available electronic data grows, it becomes more important to store such data in a manageable manner that facilitates user friendly and quick data searches and retrieval. Today, a common approach is to store electronic data in one or more databases. In general, a typical database can be referred to as an organized collection of information with data structured such that a computer program can quickly search and select desired pieces of data, for example. Commonly, data within a database is organized via one or more tables. Such tables can be arranged with rows and columns, and in many cases the data is represented differently from source to source. Ever changing data sets add to the management complexities of these databases.
In such environments, a data model plays an important role in the design of applications that interact with the database. The manner in which an application stores and retrieves data is collectively known as the application's data model. In general, the term “data model” can refer to: the abstract description how data elements are represented and/or how those elements are related to each other, and/or even the physical instantiation of those representations in bits in memory or on permanent storage.
The data model consists of several parts. The logical or abstract description of the data is known as the Schema Definition, or simply as Schema. Likewise, the set of logical behaviors provided over the data in terms of the Schema is known as the Schema API. The description of how the Schema is realized via the database system is known as the Data Model Mapping, or simply as Mapping. Additionally, the set of database primitives and their collective use in providing for the Schema API and Mapping are known as the Implementation. And, finally, the physical representation of the data in permanent or semi-permanent storage is known as the Database Layout, or just Layout. A combination of such parts is the data model, and a combination of these parts along with the data they are meant to represent is an instantiation of the data model.
Once a data model has been instantiated, it is desirable to have a flexible approach in modifying it, and to be able to change parts or all of such data model. For example, there may be a change in requirements of the application that employs the data model, and thus the data model may require modification. Moreover, implementation of new technology can allow for more efficient implementations of the existing data model or even require a new data model. Similarly, errors may become apparent in the original data model, and correction of such errors may be necessary. In the context of the invention no distinction is made between new data models that are formed by a modification of the old data model and those that are designed from scratch.
At the same time, changing the data model can also require that the data persisted according to the old model remain available under the new model. As such, generally it is necessary to produce a transformation that can be applied to the relevant data. Moreover, maintenance of the data model is typically problematic and can be further complicated by problems such as: the range of data models available (e.g., relational, object-oriented) make the description of the relationships between the new and old data models difficult; some relationships between data models are best specified explicitly while others may be more easily inferred from the definition of the data models in question; and the time it takes to apply a transformation to the data. Accordingly, a wide-range of data models have emerged over a number of years, including: relational, object-oriented and XML, each with their strengths and weaknesses. The emergence of such a wide range of data models (and their disparate implementations), in general further adds complexity to development of a generic approach to the problem of data model evolution or transformation.
For example, in a number of data models some set of transformations can be specified via a fixed set of transformation primitives. In such data models operations ranging from the simple (e.g., renaming a property/column), to the complex (e.g., changes to an object-oriented hierarchy), can occur through these defined primitives. Yet, such an approach is typically limited, in that a fixed set of primitives reduces the flexibility available to the maintainer of the data model and such primitives rarely allow transformation between radically different data models. Without a rich means of representing changes to a data model, the scope of data model evolution is therefore restricted. In still other data models, a transformation can be inferred based either on a set changes to the initial data model, or a description of the final data model and an implicit understand of the relationship between the two. Nonetheless, in such approach, the amount of information that can be inferred automatically is limited, and there exists a possibility for incorrect inferences. Moreover, combination approaches typically fail to adequately define the abilities of the transformation generation process, and the subsequent modifications that can be available.
Therefore, there is a need to overcome the aforementioned exemplary deficiencies associated with conventional systems and devices.